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Description 

BACKGROUND OF THE INVENTION 

1 . Technical Field: 

[0001] The present invention relates in general to 
techniques for securing access to software objects, and 
in particular to techniques for temporarily encrypting and 
restricting access to software objects. 

2. Description of the Related Art: 

[0002] The creation and sale of software products has 
created tremendous wealth for companies having inno- 
vative products, and this trend will continue particularly 
since consumers are becoming ever-more computer lit- 
erate as time goes on. Computer software is difficult to 
market since the potential user has little opportunity to 
browse the various products that are available. Typical- 
ly, the products are contained in boxes which are shrink- 
wrapped closed, and the potential customer has little or 
no opportunity to actually interact with or experience the 
software prior to purchasing. This causes considerable 
consumer dissatisfaction with products, since the con- 
sumer is frequently forced to serially purchase a plurality 
of software products until an acceptable product is dis- 
covered. This is perhaps one significant cause of the 
great amount of software piracy which occurs in our 
economy. A potential software purchaser will frequently 
"borrow" a set of diskettes from a friend or business as- 
sociate, with the stated intention of using the software 
for a temporary period. Frequently, such temporary use 
extends for long intervals and the potential customer 
may never actually purchase a copy of the software 
product, and may instead rely upon the borrowed copy. 
[0003] Since no common communication channel ex- 
ists for the sampling of software products, such as those 
created in movie theaters by movie trailers, and in tele- 
vision by commercials, software manufacturers are 
forced to rely upon printed publications and direct mail 
advertisements in order to advertise new products and 
solicit new customers. Unfortunately, printed publica- 
tions frequently fail to provide an accurate description 
of the product, since the user interaction with the product 
cannot be simulated in a static printed format. The man- 
ufacturers of computer software products and the cus- 
tomers would both be well served if the customers could 
have access to the products prior to making decisions 
on whether or not to purchase the product, if this could 
be accomplished without introducing risk of unlawful uti- 
lization of the product. 

[0004] The distribution of encrypted software prod- 
ucts is one mechanism a software vendor can utilize to 
distribute the product to potential users prior to pur- 
chase; however, a key must be distributed which allows 
the user access to the product. The vendor is then 
forced to rely entirely upon the honesty and integrity of 



a potential customer. Unscrupulous or dishonest indi- 
viduals may pass keys to their friends and business as- 
sociates to allow unauthorized access. It is also possible 
that unscrupulous individuals may post keys to publicly- 

5 accessible bulletin boards to allow great numbers of in- 
dividuals to become unauthorized users. Typically, 
these types of breaches in security cannot be easily pre- 
vented, so vendors have been hesitant to distribute soft- 
ware for preview by potential customers. 

10 Some attempts for solving this problem of data protec- 
tion are known in prior art: 

WO 94/07204 discloses a software copy protection 
method. A permanent use mode can be started only if 
an appropriate licensing procedure has been followed. 

15 a file management program is used for this restriction 
purpose. The file management program is represented 
in the patent application WO 94/07204 by the length of 
code or digital data and is included in the software object 
to be protected. This approach, however, has the disad- 

20 vantage that, for each protected software object, a file 
management program is necessary and it is not very se- 
cure to have this file management program inside the 
software object. Further it is difficult to implement a tem- 
porarily limited of use for the protected software. 

25 [0005] Another kind of software copy protection 
mechanism is disclosed in patent application EP-A- 
0268 139. It describes the management and manipula- 
tion of rights to execute software to hinder illegal copying 
of the software. The rights to execute, when installed on 

30 a computer system, are stored in a coprocessor element 
of the composite computer system. But the requirement 
of a separate coprocessor is a disadvantageous addi- 
tive. 

[0006] A further patent application EP-A-0561 685 
35 discloses also an electronic data protection system. An 
encrypted permission information is generated by en- 
crypting an electronic data decrypting key based on a 
medium key, which is itself generated from a medium 
number taken from the storage medium, which holds the 
40 software to be protected. But that disclosure needs a 
storage medium between the vendor computer and the 
user computer. In said storage medium a medium 
number, a permission information and the encrypted 
electronic data are stored. By using such an additional 
45 storage medium this method is an awkward method of 
electronic data protection. 

IBM Technical Disclosure Bulletin, Vol.33, No. 12, May 
1 991 , New York, US; pages 70-71 'Information Distribu- 
tion via ROM Disks' describes distributing a separate 

50 unloader program together with a program product on 
a CD ROM. This is used for a one-time installation of 
product parts and documentation to a designated com- 
puter system. But such a kind of distribution is not very 
useful for allowing the user a temporary trial period with 

55 enough security against software piracy. 
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SUMMARY OF THE INVENTION 

[0007] It is an object of the present invention to pro- 
vide a method and apparatus for distributing a software 
object from a source to a user, wherein a software object 5 
is encrypted utilizing a long-lived encryption key, and di- 
rected from the source to the user. The encrypted soft- 
ware object is loaded onto a user-controlled data 
processing system having a particular system configu- 
ration. A numerical machine identification based at least 10 
in part upon the particular configuration of the user-con- 
trolled data processing system is then derived. Next, the 
numerical machine identification is communicated to the 
source operator. Next, a temporary key is derived which 
is based at least in part upon the numerical machine 15 
identification and the long-lived encryption key. The 
temporary key is then communicated from the source to 
the user. A long-lived key generator is provided for re- 
ceiving the temporary key and producing the long-lived 
encryption key at the user. The temporary key allows 20 
the user to generate for a prescribed interval the long- 
lived encryption key to access the software object. 
These operations are performed principally by a file 
management program which is operable in a plurality of 
modes. These modes include a set up mode of opera- 25 
tion, a machine identification mode of operation, and a 
temporary key derivation mode of operation. During the 
set up mode of operation, the file management program 
is loaded onto a user-controlled data processing system 
and associated with an operating system for the user- 30 
controlled data processing system. During the machine 
identification mode of operation, the file management 
program is utilized to derive a numerical machine iden- 
tification based upon at least on attribute of the user- 
controlled data processing system. During the tempo- 35 
rary key derivation mode of operation, a temporary key 
is derived which is based at least in part upon the nu- 
merical machine identification. The file management 
program also allows atrial mode of operation, wherein 
the file management program is utilized by executing it 40 
with the user-controlled data processing system to re- 
strict access to the software object for an interval de- 
fined by the temporary key, during which the long-lived 
key generator is utilized in the user-controlled data 
processing system to provide the long-lived key in re- 45 
sponse to receipt of at least one input including the tem- 
porary key. 

[0008] The invention is defined according to method 
claims 1 and 7, and apparatus claim 9. 
[0009] The above as well as additional objectives, 50 
features, and advantages of the present invention will 
become apparent in the following detailed written de- 
scription. 

BRIEF DESCRIPTION OF THE DRAWINGS 

[0010] The novel features believed characteristic of 
the invention are set forth in the appended claims. The 



invention itself, however, as well as a preferred mode of 
use, further objectives and advantages thereof, will best 
be understood by reference to the following detailed de- 
scription of an illustrative embodiment when read in con- 
junction with the accompanying drawings, wherein: 

Figure 1 is a pictorial representation of a stand- 
alone data processing system, a telephone, and a 
variety of computer-accessible memory media all of 
which may be utilized in the implementation of the 
preferred technique of enabling trial period use of 
software products; 

Figure 2 is a pictorial representation of a distributed 
data processing system which may utilize the tech- 
nique of the present invention of enabling trial peri- 
od use of software products; 

Figure 3 is a block diagram representation of data 
processing system attributes which may be utilized 
to generate a machine identification, in accordance 
with the present invention; 

Figure 4 is a block diagram depiction of a routine 
for encrypting software objects; 

Figure 5 is a pictorial representation of the ex- 
change of information between a source (a software 
vendor) and a user (a customer), in accordance with 
the teachings of the present invention; 

Figure 6 is a flowchart representation of the broad 
steps employed in building a user interface shell, in 
accordance with the present invention; 

Figure 7 is aflowchart representation of vendor and 
customer interaction in accordance with the present 
invention; 

Figures 8, 9, 10a, and 10b depict user interface 
screens which facilitate trial period operations in ac- 
cordance with the present invention; 

Figure 1 1 depicts a user interface which is used to 
initiate a temporary access key; 

Figure 12 is a block diagram depiction of the pre- 
ferred technique of generating a machine identifica- 
tion; 

Figure 1 3 is a block diagram depiction of an encryp- 
tion operation which is utilized to encrypt a machine 
identification, in accordance with the present inven- 
tion; 



Figure 14 is a block diagram representation of the 
preferred technique for generating a product key, in 
accordance with the present invention; 
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Figure 15 is a block diagram representation of a 
preferred technique utilizing a temporary product 
key to generate a real key which can be utilized to 
decrypt one or more software objects; 

5 

Figures 16 and 17 depict a preferred technique of 
validating the real key which is derived in accord- 
ance with the block diagram of Figure 15; 

Figure 18 is a block diagram depiction of the pre- 10 
ferred routine for encyrpting a key file which con- 
tains information including atemporary product key; 

Figure 19 is a block diagram depiction of the pre- 
ferred technique of handling an encryption header 15 
in an encrypted file, in accordance with the present 
invention; 

Figure 20 depicts in block diagram form the tech- 
nique of utilizing a plurality of inputs in the user-con- 20 
trolled data processing system to derive the real key 
which may be utilized to decrypt an encrypted soft- 
ware object; 

Figure 21 depicts a decryption operation utilizing 25 
the real key derived in accordance with Figure 20; 

Figure 22 is a block diagram depiction of a compar- 
ison operation which is utilized to determine the va- 
lidity of the real key; 30 

Figure 23 depicts a decryption operation utilizing a 
validated real key; 

Figures 24, 25, 26, 27, 28 depict the utilization of 35 
an encryption header in accordance with the 
present invention; 

Figure 29 is a flowchart representation of the pre- 
ferred technique of providing a trial period of use for 40 
an encrypted software object; 

Figures 30 and 31 depict export and import opera- 
tions which may be utilized to perform trial period 
use operations in a distributed data processing sys- 45 
tern; 

Figures 32 and 33 provide an alternative view of 
the import and export operations which are depicted 
in Figures 30 and 31 ; 50 

Figures 34 and 35 provide a block diagram depic- 
tion of an alternative technique for performing an 
export/import operation. 



DETAILED DESCRIPTION OF PREFERRED 
EMBODIMENT 

[0011] The method and apparatus of the present in- 
vention for enabling trail period use of software products 
can be utilized in stand-alone PCs such as that depicted 
in Figure 1, or in distributed data processing systems, 
such as that depicted in Figure 2. In either event, tem- 
porary trial period access to one or more software prod- 
ucts depends upon utilization of the trial product on a 
particular data processing system with particular data 
processing system attributes. This is accomplished by 
encrypting the trial software product utilizing a tempo- 
rary access key which is based upon one or more data 
processing system attributes. Figure 3 graphically de- 
picts a plurality of system configuration attributes, which 
may be utilized in developing a temporary access key, 
as will be described in greater detail herebelow. To begin 
with, the environment of the stand-alone data process- 
ing system of Figure 1, and the distributed data 
processing system of Figure 2 will be described in de- 
tail, followed by a description of particular system con- 
figuration attributes which are depicted in Figure 3. 
[0012] With reference now to the figures and in par- 
ticular with reference to Figure 1, there is depicted a 
pictorial representation of data processing system 10 
which may be programmed in accordance with the 
present invention. As may be seen, data processing 
system 10 includes processor 12 which preferably in- 
cludes a graphics processor, memory device and cen- 
tral processor (not shown). Coupled to processor 12 is 
video display 16 which may be implemented utilizing ei- 
ther a color or monochromatic monitor, in a manner well 
known in the art. Also coupled to processor 12 is key- 
board 14. Keyboard 14 preferably comprises a standard 
computer keyboard which is coupled to the processor 
by means of a cable. 

[0013] Also coupled to processor 12 is a graphical 
pointing device, such as mouse 20. Mouse 20 is coupled 
to processor 12, in a manner well known in the art, via 
a cable. As is shown, mouse 20 may include left button 
24, and right button 26, each of which may be de- 
pressed, or "clicked", to provide command and control 
signals to data processing system 10. While the dis- 
closed embodiment of the present invention utilizes a 
mouse, those skilled in the art will appreciate that any 
graphical pointing device such as a light pen or touch 
sensitive screen may be utilized to implement the meth- 
od of the present invention. Upon reference to the fore- 
going, those skilled in the art wilt appreciate that data 
processing system 10 may be implemented utilizing a 
so-called personal computer, such as the Model 80 PS/ 
2 computer manufactured by International Business 
Machines Corporation of Armonk, New York. 
[0014] While the present invention may be utilized in 
stand-alone data processing systems, it may also be uti- 
lized in a distributed data processing system, provided 
the import and export routines of the present invention 
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are utilized to transfer one or more encrypted files, their 
encrypted key files, and associated file management 
programs through a portable memory media (such as 
diskettes or tapes) between particular data processing 
units within the distributed data processing system. 
While the import and export routines of the present in- 
vention will be described in greater detail herebelow, it 
is important that a basic distributed data processing sys- 
tem be described and understood. 
[0015] Figure 3 provides a block diagram depiction of 
a plurality of data processing system attributes which 
may be utilized to uniquely identify a particular data 
processing system (whether a stand-alone or a node in 
a distributed data processing system), and which further 
can be utilized to generate in the machine identification 
value which is utilized to derive or generate a temporary 
access product key which may be utilized to gain access 
to an encrypted product for a particular predefined trial 
interval. A data processing system may include a par- 
ticular system bus 60 architecture, a particular memory 
controller 74, bus controller 76, interrupt controller 78, 
keyboard mouse controller 80, DMA controller 66, VGA 
video controller 82, parallel controller 84, serial control- 
ler 86, diskette controller 88, and disk controller 82. Ad- 
ditionally, a plurality of empty or occupied slots 1 06 may 
be used to identify the particular data processing sys- 
tem. Each particular data processing system may have 
attributes which may be derived from RAM 70, ROM 68, 
or CMOS RAM 72. End devices such as printer 96, mon- 
itor 94, mouse 92, keyboard 90, diskette 100, or disk 
drive 1 04 may be utilized to derive one or more attributes 
of the data processing system which may be processed 
in a predetermined manner to derive a machine identi- 
fication value. The derivation of the machine identifica- 
tion value will be described in greater detail below. The 
present invention is directed to an efficient method of 
distributing software programs to users which would 
provide to them a means to try the program before ob- 
taining (by purchasing) a license for it. In accordance 
with this concept, complete programs are distributed to 
potential users on computer-accessible memory media 
such as diskettes or CD-ROMs. The concept is to gen- 
erate keys that allow the user to access the programs 
from the distributed media In this environment, a file 
management program provides a plurality of interfaces 
which allows the user to browse the different products. 
The interfaces allow ordering and unlocking of the soft- 
ware products contained on the distributed media. Un- 
locking of the software product is accomplished by the 
reception, validation, and recording of a temporary ac- 
cess (decryption) key. 

[0016] The file management program is resident in 
the user-controlled data processing system and be- 
comes a part of the operating system in the user's com- 
puter. An example of such a resident program (in the PC 
DOS environment) would be a resident program TSR, 
for "terminate and stay resident" operations, that inter- 
cepts and handles DOS file input and output operations. 



When a temporary access key is provided to a user, sys- 
tem files are checked to see if this file has been used in 
a trial mode of operation before. If the product has never 
been used in a trial mode of operation, the temporary 

5 key is saved. Once the trial mode of operation key ex- 
ists, an encrypted application can only be run if it is ini- 
tiated by the file management program. The file man- 
agement program will recognize that the application is 
encrypted and that a valid trial mode of operation key 

10 exists for the particular operation. A valid trial mode of 
application key is one that has not expired. The trial 
mode of operation may be defined by either a timer, or 
a counter. Atimercan be used to countdown aparticular 
predefined period (such as thirty days); alternatively, the 

15 counter can be used to decrement through a predefined 
number of trial "sessions" which are allowed during the 
trial mode of operation. If the key is valid, the file man- 
agement program communicates directly with the TSR 
and enables the trial mode of operation for a particular 

20 encrypted application. The file management program 
then kicks off the encrypted application. The code which 
is resident in the operating system of the user-controlled 
data processing system maintains control over the op- 
erating system. It monitors the use of the trial mode of 

25 operation keys to allow files to be decrypted and loaded 
into memory, but prevents the encrypted files from being 
decrypted and copied to media. This is done by using 
the operating system to determine which applications 
are trying to access the data and only allowing the ap- 

30 plications that have permission to access the data to do 
so. 

[0017] Figure 4 is a block diagram depiction of a rou- 
tine for encrypting software objects. The binary charac- 
ters which make up software object 201 are supplied as 

35 an input to encryption engine 205. Real key 203 is uti- 
lized as an encryption key in encryption engine 205. The 
output of encryption engine 205 is an encrypted soft- 
ware object 207. Encryption engine 205 may be any 
conventional encryption operation such as the pub- 

40 Nshed and well known DES algorithm; alternatively, the 
encryption engine 205 may be an exclusive-OR opera- 
tion which randomizes software object 201. 
[001 8] Figure 5 is a pictorial representation of the ex- 
change of information between a source 209 (a software 

45 vendor) and a user 21 1 (a potential customer, in accord- 
ance with the teachings of the present invention. The 
arrows between source 209 and user 21 1 represent ex- 
changes of objects or information between vendor 209 
and 21 1 . In the exchange of flow 203, computer-acces- 

50 sible memory media is directed from source 209 to user 
21 1 . This transfer may occur by US mail delivery, courier 
delivery, express service delivery, or by delivery through 
printed publications such as books and magazines. Al- 
ternatively, an electronic document may be transferred 

55 from source 209 to user 211 utilizing electronic mail or 
other transmission techniques. In flow 215, user-specif- 
ic information, preferably including a unique machine 
identification number which identifies the dataprocess- 
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ing system of user 211, is transferred from user 21 1 to 
source 209 via an insecure communication channel; 
typically, this information is exchanged over the tele- 
phone, but may be passed utilizing electronic mail or 
other communication techniques. In flow 217, source 
209 provides a product key to user 21 1 . The product key 
allows the product contained in the memory media to be 
temporarily accessed for a prescribed and predefined 
interval. This interval is considered to be a "trial" interval 
during which user 211 may become familiar with the 
software and make a determination on whether or not 
he or she wishes to purchase the software product. User 
211 must communicate additionally with source 209 in 
order to obtain permanent access to the software prod- 
uct. The product key allows user 211 to obtain access 
to the software product for a particular predefined time 
interval, or for a number of predefined "sessions." As 
time passes, the user's dock or counter runs down. At 
the termination of the trial period, further access is de- 
nied. Therefore, the user 211 must take affirmative 
steps to contact source 209 and purchase a permanent 
key which is communicated to user 21 1 and which per- 
manently unlocks a product to allow unrestricted access 
to the software product. 

[0019] The communication between source 209 and 
user 211 is facilitated by a user interface. The creation 
of the interface is depicted in flowchart form in Figure 
6. The process begins at software block 219, and con- 
tinues at software block 221, wherein source 209 makes 
language and locale selections which will determine the 
language and currencies utilized in the interface which 
facilitates implementation of the trial period use of the 
software products. A plurality of software products may 
be bundled together and delivered to user 21 1 on a sin- 
gle computer-accessible memory media. Therefore, in 
accordance with software block 223, source 209 must 
make a determination as to the programs which will be 
made available on a trial basis on the computer-acces- 
sible memory media, and the appropriate fields are com- 
pleted, in accordance with software block 223. Next, in 
accordance with software block 225, the programs are 
functionally limited or encrypted. Then, in accordance 
with software block 227, the shell is loaded along with 
the computer program products onto a computer-acces- 
sible memory media such as a diskette or CD ROM. The 
process ends at software block 229. 
[0020] Figure 7 is a flowchart representation of ven- 
dor and customer interaction in accordance with the 
present invention. The flow begins at software block 
231, and continues at step 233, wherein computer-ac- 
cessible memory media are distributed to users for a try- 
and-buy trial interval. Then, in accordance with step 
235, the file management program is loaded from the 
computer-accessible memory media onto a user-con- 
trolled data processing system for execution. The file 
management program includes a plurality of interface 
screens which facilitate interaction between the vendor 
and the customer, which and which set forth the options 



available to the customer. Thus, in accordance with step 
237, the file management program allows browsing and 
displays appropriate user interfaces. Next, in accord- 
ance with step 239, the customer and the vendor inter- 

5 act, typically over the telephone or electronic mail, to 
allow the vendor to gather information about the cus- 
tomer and to distribute a temporary key which allows 
access to one or more software products which are con- 
tained on the computer-accessible memory media for a 

10 predefined trial interval. Typically, the interval will be de- 
fined by an internal clock, or by a counter which keeps 
track of the number of sessions the potential purchaser 
has with a particular software product or products. Step 
241 represents the allowance of the trial interval use. 

15 Then, in accordance with software block 243, the file 
management program monitors and oversees all input 
and output calls in the data processing system to pre- 
vent unauthorized use of the encrypted software prod- 
ucts contained on the computer-accessible memory 

20 media. In the preferred embodiment of the present in- 
vention, the file management program monitors for calls 
to encrypted files, and then determines whether access 
should be allowed or denied before the file is passed for 
further processing. The customer can assess the soft- 

25 ware product and determine whether he or she desires 
to purchase it. If a decision is made to purchase the 
product, the customer must interact once again with the 
vendor, and the vendor must deliver to the customer a 
permanent key, as is set forth in step 245. The process 

30 ends when the customer receives the permanent key, 
decrypts the one or more software products that he or 
she has purchased, and is then allowed ordinary and 
unrestricted access to the software products. 
[0021] Figures 8, 9, 10a, and 10b depict user inter- 
ns face screens which facilitate trial period operations in 
accordance with the present invention. Figure 8 depicts 
an order form user interface 249 which is displayed 
when the customer selects a "view order" option from 
another window. The order form user interface 249 in- 

40 eludes a title bar 251 which identifies the software ven- 
dor and provides a telephone number to facilitate inter- 
action between the potential customer and the vendor. 
An order form field 255 is provided which identifies one 
or more software products which may be examined dur- 

45 jng a trial interval period of operation. A plurality of sub- 
fields are provided including quantity subfield 259, item 
subfield 257, description subfield 260, and price subfield 
253. Delete button 261 allows the potential customer to 
delete items from the order form field. Subtotal field 263 

50 provides a subtotal of the prices for the ordered soft- 
ware. Payment method icons 265 identify the accepta- 
ble forms of payment. Of course, a potential user may 
utilize the telephone number to directly contact the ven- 
dor and purchase one or more software products; alter- 

55 natively, the user may select one or more software prod- 
ucts for a trial period mode of operation, during which a 
software product is examined to determine its adequa- 
cy. A plurality of function icons 267 are provided at the 
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lowermost portion of order form interface 249. These in- 
clude a close icon, fax icon, mail icon, print icon, unlock 
icon, and help icon. The user may utilize a graphical 
pointing device in a conventional point-and-click opera- 
tion to select one or more of these operations. The fax 
icon facilitates interaction with the vendor utilizing a fac- 
simile machine or facsimile board. The print icon allows 
the user to generate a paper archival copy of the inter- 
action with the software vendor. 

[0022] The customer, the computer-accessible mem- 
ory media, and the computer system utilized by the cus- 
tomer are identified by media identification 269, custom- 
er identification 273, and machine identification 271. 
The media identification is assigned to the computer- 
accessible memory media prior to shipping to the po- 
tential customer. It is fixed, and cannot be altered. The 
customer identification 273 is derived from interaction 
between the potential customer and the vendor. Prefer- 
ably, the customer provides answers to selected ques- 
tions in a telephone dialogue, and the vendor supplies 
a customer identification 273, which is unique to the par- 
ticular customer. The machine identification 271 is au- 
tomatically derived utilizing the file management pro- 
gram which is resident on the computer-accessible 
memory media, and which is unique to the particular da- 
ta processing system being utilized by the potential cus- 
tomer. The potential customer will provide the machine 
identification to the vendor, typically through telephone 
interaction, although fax interaction and regular mail in- 
teraction is also possible. 

[0023] Figure 9 is a representation of an order form 
dialog interface 275. This interface facilitates the acqui- 
sition of information which uniquely identifies the poten- 
tial customer, and includes name field 277, address field 
279, phone number field 281, facsimile number field 
283, payment method field 285, shipping method field 
287, account number field 289, expiration date field 291 , 
value added tax ID field 293. Order information dialog 
interface 275 further includes print button 295 and can- 
cel button 297 which allow the potential user to delete 
information from these fields, or to print a paper copy of 
the interface screen. 

[0024] Figures 10a and 10b depict unlock dialog in- 
terface screens 301, 303. The user utilizes a graphical 
pointing device to select one or more items which are 
identified by the content item number field 307 and de- 
scription field 309 which are components of unlock list 
305. The interface further includes customer I D field 31 3 
and machine ID field 315. Preferably, the vendor pro- 
vides the customer identification to the customer in an 
interaction via phone, fax, or mail. Preferably, the cus- 
tomer provides to the vendor the machine identification 
within machine identification field 315 during interaction 
via phone, fax, or mail. Once the information is ex- 
changed, along with an identification of the products 
which are requested for a trial interval period of opera- 
tion, a temporary access key is provided which is locat- 
ed within key field 31 1 . The key will serve to temporarily 



unlock the products identified and selected by the cus- 
tomer. Close button 319, save button 317, and help but- 
ton 321 are also provided in this interface screen to fa- 
cilitate user interaction. 
5 [0025] Figure 10b depicts a single-product unlock in- 
terface screen 303. This interface screen includes only 
machine identification field 315, customer identification 
field 31 5, and key field 31 1 . The product which is being 
unlocked need not be identified in this interface, since 
the dialog pertains only to a single product, and it is as- 
sumed that the user knows the product for which a tem- 
porary trial period of operation is being requested. Save 
button 317, cancel button 319, and help button 321 are 
also provided in this interface to facilitate operator inter- 
action. 

[0026] Figure 11 depicts a user interface screen 
which is utilized in unlocking the one or more encrypted 
products for the commencement of a trial interval mode 
of operation. The starting date dialog of Figure 11 is 
displayed after the "SAVE" push button is selected in 
the unlock dialog of either Figure 10a or Figure 10b. 
The user will be prompted to verify the correct starting 
date which is provided in date field 310. The user re- 
sponds to the query by pointing and clicking to either the 
"continue" button 312, the "cancel" button 314, or the 
"help" button 316. The date displayed in field 310 is de- 
rived from the system dock of the user-controlled data 
processing system. The user may have to modify the 
system clock to make the date correspond to the official 
or stated date of commencement of the trial period of 
operation. 

[0027] A trial interval operation can take two forms: 
one form is a functionally disabled product that allows a 
user to try all the features, but may not allow a critical 
function like printing or saving of data files. Another type 
of trial interval is a fully functional product that may be 
used for a limited time. This requires access protection, 
and allows a customer to try all the functions of a product 
for free or for a nominal fee. Typically, in accordance 
with the present invention, access to the product is con- 
trolled through a "timed" key. The trial period for using 
the product is a fixed duration determined by the vendor. 
The trial period begins when the key is issued. In ac- 
cordance with the present invention, the products being 
previewed during the trial interval of operation can only 
be run from within a customer shell. A decryption driver 
will not allow the encrypted products to be copied in the 
clear, nor will it allow the product to be run outside the 
customer's shell. In an alternative embodiment, the trial 
interval is defined by a counter which is incremented or 
decremented with each "session" the customer has with 
the product. This may allow the customer a predefined 
number of uses of the product before decryption is no 
longer allowed with the temporary key. 
[0028] The limits of the temporary access key are built 
into a "control vector" of the key. Typically, a control vec- 
tor will include a short description of the key, a machine 
identification number, and a formatted text string that in- 
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eludes the trial interval data (such as a dock value or a 
counter value). The control vector cannot be altered 
without breaking the key. When a protected software 
product is run, the usage data must be updated to en- 
force the limits of the trial interval period of operation. In 
order to protect the clock or counter from tampering, its 
value is recorded in a multiple number of locations, typ- 
ically in encrypted files. In the preferred embodiment of 
the present invention, the trial interval information (clock 
value and/or cou nter value) is copied to a "key file" which 
will be described in further detail herebelow, to a ma- 
chine identification file, which will also be discussed her- 
ebelow, and to a system file. When access to an en- 
crypted program is requested, all of these locations are 
checked to determine if the value for the clock and/or 
counter is the same. It is unlikely that an average user 
has the sophistication to tamper successfully with all 
three files, in the preferred embodiment, a combination 
of a dock and a counter is utilized to prevent extended 
use of backup and restore operations to reset the sys- 
tem dock. Although it is possible to reset a PC's dock 
each time a trial use is requested, this can also be de- 
tected by tracking the date/time stamps of certain files 
on the system and using the most recent date between 
file date/time stamps and the system clock. As stated 
above, one of the three locations the timer and/or coun- 
ter information is stored is a system file. When operating 
in an OS/2 operating system, the time and usage data 
can be stored in the system data files, such as the 
OS2.INI in the OS/2 operating system. The user will 
have to continuously backup and restore these files to 
reset the trial and usage data. These files contain other 
data that is significant to the operation of the user sys- 
tem. The casual user can accidentally lose important da- 
ta for other applications by restoring these files to an 
older version. In the present invention, these protection 
techniques greatly hinder a dishonest user's attempts 
to extend the trial interval use beyond the authorized 
interval. 

[0029] In broad overview, in the present invention, the 
vendor loads a plurality of encrypted software products 
onto a computer-accessible memory media, such as a 
CD ROM or magnetic media diskette. Also loaded onto 
the computer-accessible memory media is a file man- 
agement program which performs a plurality of func- 
tions, including the function of providing a plurality of us- 
er interface screens which facilitate interaction between 
the software vendor and the software customer. The 
computer-accessible memory media is loaded onto a 
user-controlled data processing and the file manage- 
ment program is loaded for execution. The file manage- 
ment program provides a plurality of user-interface 
screens to the software customer which gathers infor- 
mation about the customer (name, address, telephone 
number, and billing information) and receives the cus- 
tomer selections of the software products for which a 
trial interval is desired. Information is exchanged be- 
tween the software vendor and card customer, includ- 



ing: a customer identification number, a product identi- 
fication number, a media identification number, and a 
machine identification number. The vendor generates 
the customer identification number in accordance with 
5 its own internal record keeping. Preferably, the repre- 
sentative of the software vendor gathers information 
from the software customer and types this information 
into a established blank form in order to identify the po- 
tential software customer. Alternatively, the software 
10 vendor may receive a facsimile or mail transmission of 
the completed order information dialog interface screen 
275 (of Figure 9). The distributed memory media (such 
as CDs and diskettes) also include a file management 
program which is used to generate a unique machine 
15 identification based at least in part upon one attribute of 
the user-controlled data processing system. This ma- 
chine identification is preferably a random eight-bit 
number which is created during a one-time setup proc- 
ess. Preferably, eight random bits are generated from a 
20 basic random number generator using the system time 
as the "seed" for the random number generator. Prefer- 
ably, check bits are added in the final result. Those 
check bits are critical to the order system because per- 
sons taking orders must key in the machine ID that the 
25 customer reads over the phone. The check bits allow for 
instant verification of the machine ID without requiring 
the customer to repeat the number. Preferably, a master 
file is maintained on the user-controlled data processing 
system which contains the dear text of the machine 
30 identification and an encrypted version of the machine 
identification. 

[0030] When the software customer places an order 
for a temporary trial use of the software products, he or 
she verbally gives to the telephone representative of the 
35 software vendor the machine identification. In return, the 
telephone representative gives the software customer 
a product key which serves as a temporary access key 
to the encrypted software products on the computer-ac- 
cessible memory media, as well as a customer identifi- 
40 cation number. Preferably, the product key is a function 
of the machine identification, the customer number, the 
real encryption key for the programs or programs or- 
dered, and a block of control data. The software cus- 
tomer may verify the product key by combining it with 
45 the customer number, and an identical block of control 
data to produce the real encryption key. This key is then 
used to decrypt an encrypted validation segment, to al- 
low a compare operation. If the encrypted validation 
segment is identical to known clear text for the validation 
50 segment, then the user's file management program has 
determined that the product key is a good product key 
and can be utilized for temporary access to the software 
products. Therefore, if the compare matches, the key is 
stored on the user-controlled data processing system in 
55 a key file. Preferably, the key file contains the product 
key, a customer key (which is generated from the cus- 
tomer number and an internal key generating key) and 
a clear ASCII string containing the machine identifica- 
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tion. All three items must remain unchanged in order for 
the decryption tool to derive the real encryption key. To 
further tie the key file to this particular user-controlled 
data processing system, the same key file is encrypted 
with a key that is derived from system parameters. 
These system parameters may be derived from the con- 
figuration of the data processing system. 
[0031] Stated broadly, in the present invention the 
temporary key (which is given verbally over the phone, 
typically) is created from an algorithm that utilizes en- 
cryption to combine the real key with a customer 
number, the machine identification number, and other 
predefined dear text. Thus, the key is only effective for 
a single machine: even if the key were to be given to 
another person, it would not unlock the program on that 
other person's machine. This allows the software vendor 
to market software programs by distributing complete 
programs on computer-accessible memory media such 
as diskettes or CD ROMs, without significant risk of the 
loss of licensing revenue. 

[0032] Some of the preferred unique attributes of the 
system which may be utilized for encryption operations 
include the hard disk serial number, the size and format 
of the hard disk, the system model number, the hard- 
ware interface cards, the hardware serial number, and 
other configuration parameters. The result of this tech- 
nique is that a machine identification file can only be de- 
crypted on a system which is an identical clone of the 
user-controlled data processing system. This is very dif- 
ficult to obtain, since most data processing systems 
have different configurations, and the configurations 
can only be matched through considerable effort. These 
features will be described in detail in the following written 
description. 

[0033] Turning now to Figure 12, the file management 
program receives the distributed computer-accessible 
memory media with encrypted software products and a 
file management program contained therein. The file 
management program assesses the configuration of the 
user-controlled data processing system, as represented 
in step 351 of Figure 12. The user-specific attributes of 
the data processing system are derived in step 353, and 
provided as an input to machine identification generator 
355, which is preferably a random number generator 
which receives a plurality of binary characters as an in- 
put, and generates a pseudo-random output which is 
representative of machine identification 357. The proc- 
ess employed by machine identification generator 355 
is any conventional pseudo-random number generator 
which receives as an input of binary characters, and pro- 
duces as an output a plurality of pseudo-random binary 
characters, in accordance with a predefined algorithm. 
[0034] With reference now to Figure 13, machine 
identification 357 is also maintained within the file man- 
agement program in an encrypted form. Machine iden- 
tification 357 is supplied as an inputto encryption engine 
359 to produce as an output the encrypted machine 
identification 361 . Encryption engine 359 may comprise 



any convention encryption routine, such as the DES al- 
gorithm. A key 363 is provided also as an input to en- 
cryption engine 359, and impacts the encryption opera- 
tion in a conventional manner. Key 363 is derived from 
5 system attribute selector 365. The types of system at- 
tributes which are candidates for selection include sys- 
tem attribute listing 367 which includes: the hard disk 
serial number, the size of the hard disk, the format of the 
hard disk, the system model number, the hardware in- 
fo terface card, the hardware serial number, or other con- 
figuration parameters. 

[0035] In accordance with the present invention, the 
clear text machine identification 357 and the encrypted 
machine identification 361 are maintained in memory. 
15 Also, in accordance with the present invention, the file 
management program automatically posts the dear text 
machine identification 357 to the appropriate user inter- 
face screens. The user then communicates the machine 
identification to the software vendor where it is utilized 
20 in accordance with the block diagram of Figure 14. As 
is shown, product key encryption engine 375 is main- 
tained within the control of the software vendor. This 
product key encryption engine 375 receives as an input: 
the machine identification 357, a customer number 369 
25 (which is assigned to the customer in accordance with 
the internal record keeping of this software vendor), the 
real encryption key 371 (which is utilized to decrypt the 
software products maintained on the computer-acces- 
sible memory media within the custody of the software 
30 customer), a control block text 373 (which can be any 
predefined textural portion), and trial interval data 374 
(such as clock and/or counter value which defines the 
trial interval of use). Product key encryption engine pro- 
duces as an output a product key 377. Product key 377 
35 may be communicated to the software customer via an 
insecure communication channel, without risk of reveal- 
ing real key 371 . Real key 371 is masked by the encryp- 
tion operation, and since the product key 377 can only 
be utilized on a data processing system having a con- 
40 figuration identical to that from which machine identifi- 
cation 357 has been derived, access to the encrypted 
software product is maintained in a secure condition. 
[0036] Upon delivery of product key 377, the file man- 
agement program resident in the user-controlled data 
45 processing system utilizes real key generator 379 to re- 
ceive a plurality of inputs, including product key 377, 
customer number 369, control block text 373, machine 
identification 357 and trial interval data 374. Real key 
generator 379 produces as an output the derived real 
50 key 381 . 

[0037] Next, as is depicted in Figures 16 and 17, the 
derived real key 381 is tested to determine the validity 
and authenticity of the product key 377 which has been 
provided by the software vendor. As is shown, the de- 
55 rived real key 381 is supplied as an input to encryption 
engine 385. A predetermined encrypted validation data 
segment 383 is supplied as the other input to encryption 
engine 385. Encryption engine supplies as an output de- 
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rived clear validation text 387. Then, in accordance with 
Figure 17, the derived clear validation text 387 is com- 
pared to the known clear validation text 391 in compa- 
rator 389. Comparator 389 simply performs a bit-by-bit 
comparison of the derived clear validation text 387 with 
the known clear validation text 391 . If the derived clear 
validation text 387 matches the known clear validation 
text 391, a key file is created in accordance with step 
393; however, if the derived clear validation text 387 
does not match the known clear validation text 391, a 
warning is posted to the user-controlled data processing 
system in accordance with step 395. 
[0038] Turning now to Figure 18, key file 397 is de- 
picted as including the temporary product key, the cus- 
tomer key (which is an encrypted version of the custom- 
er number), the machine identification number in clear 
text and the trial interval data (such as a clock and/or 
counter value). This key file is supplied as an input to 
encryption engine 399. Key 401 is also provided as an 
input to encryption engine 399. Key 401 is derived from 
unique system attributes 403, such as those system at- 
tributes utilized in deriving the machine identification 
number. Encryption engine 399 provides as an output 
the encrypted key file 405. 

[0039] Figures 19, 20, 21, 22, and 23 depict opera- 
tions of the file management program after a temporary 
access key has been received, and validated, and re- 
corded in key file 397 (of Figure 18). 
[0040] Figure 1 9 is a block diagram representation of 
the steps which are performed when an encrypted soft- 
ware product is called for processing by the user-control 
data processing system. The encrypted file 405 is 
fetched, and a "header" portion 407 is read by the user- 
controlled data processing system. The header has a 
number of components including the location of the key 
file. The location of the key file is utilized to fetch the key 
file in accordance with step 409. The header further in- 
cludes an encrypted validation text 411. The encrypted 
validation text 411 is also read by the user-controlled 
data processing system. As is stated above (and depict- 
ed in Figure 18) the key file includes the product key 
41 9, a customer key 41 7, and the machine identification 
415. These are applied as inputs to decryption engine 
413. Decryption engine 413 provides as an output real 
key 421. Before real key 421 is utilized to decrypt en- 
crypted software products on the distributed memory 
media, it is tested to determine its validity. Figure 21 is 
a block diagram of the validation testing. Encrypted val- 
idation text 423, which is contained in the "header", is 
provided as an input to decryption engine 425. Real key 
421 (which was derived in the operation of Figure 20) 
is also supplied as an input to decryption engine 425. 
Decryption engine 425 provides as an output clear val- 
idation text 427. As is set forth in block diagram form in 
Figure 22, clear validation text 427 is supplied as an 
input to comparator 429. The known clear vaiidaiion text 
431 is also supplied as an input to comparator 429. 
Comparator 429 determines whether the derived clear 



validation text 427 matches the known dear validation 
text 431. If the texts match, the software object is de- 
crypted in accordance with step 433; however, if the val- 
idation text portions do not match, a warning is post in 

5 accordance with step 435. Figure 23 is a block diagram 
depiction of the decryption operation of step 433 of Fig- 
ure 22. The encrypted software object 437 is applied as 
an input to decryption engine 439. The validated real 
key 441 is also supplied as an input to decryption engine 

10 439. Decryption engine 439 supplies as an output the 
decrypted software object 443. 

[0041] The encryption header is provided to allow for 
the determination of whether or not a file is encrypted 
when that file is stored with clear-text files. In providing 

15 the encryption header for the encrypted file, it is impor- 
tant that the file size not be altered because the size 
may be checked as part of a validation step (unrelated 
in any way to the concept of the present invention) dur- 
ing installation. Therefore, making the file larger than it 

20 is suppose to be can create operational difficulties dur- 
ing installation of the software. The encryption header 
is further necessary since the file names associated with 
the encrypted software products cannot be modified to 
reflect the fact that the file is encrypted, because the 

25 other software applications that may be accessing the 
encrypted product will be accessing those files utilizing 
the original file names. Thus, altering the file name to 
indicate that the file is encrypted would prevent benefi- 
cial and desired communication between the encrypted 

30 software product and other, perhaps related, software 
products. For example, spreadsheet applications can 
usually port portions of the spreadsheet to a related 
word processing program to allow the integration of fi- 
nancial information into printed documents. Changing 

35 the hard-coded original file name for the word process- 
ing program would prevent the beneficial communica- 
tion between these software products. The encryption 
header of the present invention resolves these problems 
by maintaining the encrypted file at its nominal file 

40 length, and by maintaining the file name for the software 
product in an unmodified form. 

[0042] Figure 24 graphically depicts an encrypted file 
with encryption header 451 . The encryption header 451 
includes a plurality of code segments, including: unique 

45 identifier portion 453, the name of the key file portion 
455, encrypted validation segment 457, encryption type 
459, offset to side file 461, and encrypted file data 463. 
Of course, in this view, the encrypted file data 463 is 
representative of the encrypted software product, such 

50 as a word processing program or spreadsheet The en- 
cryption header 451 is provided in place of encrypted 
data which ordinarily would comprise part of the encrypt- 
ed software product. The encryption header is substitut- 
ed in the place of the first portion of the encrypted soft- 

55 ware product In order to place the encryption header 
451 at the front of the encrypted software product of en- 
crypted file data 463, a portion of the encrypted file data 
must be copied to another location. Offset to side file 
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461 identifies that side file location where the displaced 
file data is contained. 

[0043] Figure 25 graphically depicts the relationship 
between the directory of encrypted files and the side 
files. As is shown, the directory of encrypted files 465 
includes file aaa, file bbb, file ccc, file ddd, through file 
nnn. Each of these files is representative of a directory 
name for a particular encrypted software product. Each 
encrypted software product has associated with it a side 
file which contains the front portion of the file which has 
been displaced to accommodate encryption header 451 
without altering the size of the file, and without altering 
the file name. File aaa has associated with it a side file 
AAA. Software product file bbb has associated with it 
a side file BBB. Encrypted software product ccc has as- 
sociated with it a side file CCC. Encrypted software 
product ddd has associated with it a side file DDD. En- 
crypted software product nnn has associated with it a 
side file NNN. In Figure 25, directory names 467, 469, 
471, 473, 475 are depicted as being associated with 
side files 477, 479, 481, 483, and 485. The purpose of 
the side files is to allow each of the encrypted software 
products to be tagged with an encryption header without 
changing the file size. 

[0044] Encryption type segment 459 of the encryption 
header 451 identifies the type of encryption utilized to 
encrypt the encrypted software product. Any one of a 
number of conventional encryption techniques can be 
utilized to encrypt the product, and different encryption 
types can be utilized to encrypt different software prod- 
ucts contained on the same memory media. Encryption 
type segment 459 ensures that the appropriate encryp- 
tion/decryption routine is called so that the encrypted 
software product may be decrypted, provided the tem- 
porary access keys are valid and not expired. The name 
of key file segment 455 of encryption header 451 pro- 
vides an address (typically a disk drive location) of the 
key file. As is stated above (in connection with Figure 
1 8) the key file includes the product key, a customer key, 
and the clear machine ID. All three of these pieces of 
information are required in order to generate the real key 
(in accordance with Figure 20). Encrypted validation 
segment 457 includes the encrypted validation text 
which is utilized in the routine depicted in Figure 21 
which generates a derived clear validation text which 
may be compared utilizing the routine of Figure 22 to 
the known dear validation text. Only if the derived clear 
validation text exactly matches the known clear valida- 
tion text can the process continue by utilizing the derived 
and validated real key to decrypt the encrypted software 
product in accordance with the routine of Figure 23. 
However, prior to performing the decryption operations 
of Figure 23, the contents of the corresponding side file 
must be substituted back into the encrypted software 
product in lieu of encryption header 451. This ensures 
that the encrypted software product is complete prior to 
the commencement of decryption operations. 
[0045] Each time a file is called for processing by the 



operating system of the user-controlled data processing 
system, the file management program which is resident 
in the operating system intercepts the input/output re- 
quests and examines the front portion of the file to de- 

5 termine if a decryption block identifier, such as unique 
identifier 453, exists at a particular known location. For 
best performance, as is depicted in Figure 24, this lo- 
cation will generally be at the beginning of the file. If the 
file management program determines that the file has 

10 the decryption block, the TSR will read the block into 
memory. The block is then parsed in order to build a fully 
qualified key file name by copying an environment var- 
iable that specifies the drive and directory containing the 
key files and concatenating the key file name from the 

15 encryption block. The TSR then attempts to open the 
key file. If the key file does not exist, the TSR returns an 
"access denied" response to the application which is at- 
tempting to open the encrypted file. If the key file is de- 
termined to exist, the TSR opens the key file and reads 

20 in the keys (the product key, the customer key, and the 
machine identification) and generates the real key. This 
real key is in use to decrypt the decryption block valida- 
tion data. As is stated above, a comparison operation 
determines whether this decryption operation was suc- 

25 cessful. If the compare fails, the key file is determined 
to be "invalid", and the TSR returns an "access denied 
message" to the application which is attempting to open 
the encrypted software product. However, if the com- 
pare is successful, the file management program pre- 

30 pares to decrypt the file according to the encryption type 
found in the encryption header. The TSR then returns a 
valid file handle to the calling application to indicate that 
the file has been opened. When the application reads 
data from the encrypted file, the TS R reads and decrypts 

35 this data before passing it back to the application. If the 
data requested is part of the displaced data that is stored 
in the side file, the TSR will read the side file and return 
the appropriate decrypted block to the calling applica- 
tion without the calling application being aware that the 

40 data came from a separate file. 

[0046] While the broad concepts of the encryption 
header are depicted in Figures 24 and 25, the more par- 
ticular aspects of creating the encrypted files are depict- 
ed in Figures 26, 27, and 28. Figures 27 and 28 depict 

45 two types of data files. Figure 27 depicts a non-execut- 
ing data file, while Figure 28 depicts an executing data 
file. Figure 26 depicts a header 499 which includes sig- 
nature segment 501, header LEN 503, side file index 
505, side file LEN 507, decryption type identifier 509, 

50 verification data 511, and key file name 51 8. As is shown 
in Figure 27, a software product begins as a clear file 
521, and is encrypted in accordance with a particular 
encryption routine into encrypted file 523. Encryption 
type segment 509 of header 499 identifies the type of 

55 encryption utilized to change dear file 521 to encrypted 
file 523. Next, the front portion of encrypted file 523 is 
copied to side file 527 which is identified by side file in- 
dex 505 and side file LEN 507 of header 499. Addition- 
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ally, a copy of the clear text of the verification data is 
also included in side file 527. Then, header 499 is copied 
to the front portion of encrypted file 523 to form modified 
encrypted files 525. A similar process is employed for 
executing files, as depicted in Figure 28. The dear text 
copy of the software product (represented as clear file 
531) is encrypted in accordance with a conventional rou- 
tine, to form encrypted file 533. The front portion of en- 
crypted file 533 is copied to side file 539 so that the over- 
laid data of encrypted file 533 is preserved. Further- 
more, side file 539 includes a copy of the clear text of 
the verification data. Then, the encrypted file 533 is 
modified by overlaying and executable stub 537 and 
header 599 onto the first portion of encrypted file 553. 
[0047] The purpose of executable stub 537 of Figure 
28 will now be described. The DOS operating system 
for a personal computer will try to execute an encrypted 
application. This can result in a system "hang" or unfa- 
vorable action. The executable stub 357 of the execut- 
ing file of Figure 28 is utilized to protect the user from 
attempting to execute applications that are encrypted: 
there would be considerable risk that a user would hang 
his system or format a drive if he or she try to run an 
encrypted file. The executable stub is attached to the 
front portion of the encrypted software product so that 
this stub is executed whenever the application is run 
without the installed TSR or run from a drive the TSR is 
not "watching". This stub will post a message to the user 
that explains why the application cannot run. In addition 
to providing a message, this executable stub can be 
used to perform sophisticated actions, such as: 

(1 ) it can duplicate the functionality of the TSR and 
install dynamic encryption before kicking off the ap- 
plication a second time; 

(2) it can turn on a temporary access key and kick 
off the application a second time; 

(3) it can communicate with the TSR and inform it 
to look at the drive the application is being run from. 

[0048] The executable stub is saved or copied into the 
encrypted program as follows: 

(1) the application is encrypted; 

(2) a decryption block is created for this program; 

(3) a pre-built executable stub is attached to the 
front end of the decryption block; 

(4) the length of the combined decryption header 
and executable stub is determined; 

(5) the bytes at the front of the executable file equal 
to this length are then read into memory, preferably 
into a predefined side file location; and 

(6) the encryption header and executable stub are 
then written over the leading bytes in the executable 
code. 

[0049] The TSR can determine if an executable is en- 
crypted by searching beyond the "known size" of the ex- 



ecutable stub for the decryption block portion. When the 
TSR decrypts the executable stub it accesses the side 
file to read in the bytes that were displaced by the stub 
and header block. 
5 [0050] Figure 29 provides a flowchart representation 
of operation during a trial period interval, which begins 
at software block 601. In accordance with software block 
603, the file management program located in the oper- 
ating system of the user-controlled data processing sys- 
tem continually monitors for input/output calls to the 
memory media. Then, in accordance with software 
block 605, for each input/output call, the called file is 
intercepted, and in accordance with software block 607 
the operating system is denied access to the called file, 
until the file management program can determine 
whether access should be allowed or not. A portion of 
the called file is read where the decryption block should 
be located. This portion of the called file is then read, in 
accordance with software block 609, to derive a key file 
address in accordance with software block 61 1 . The ad- 
dress which is derived is utilized to fetch the key file, in 
accordance with software block 61 3. In accordance with 
decision block 615, if the key file cannot be located, the 
process ends at software block 61 7; however, if if is de- 
termined in decision block 615 that the key file can be 
located, the key is derived in accordance with software 
block 619. The derived key is then utilized to decrypt the 
validation segment which is located within the encryp- 
tion header, in accordance with software block 621. In 
decision block 623, the decryption validation segment 
is compared to the dear text for the decryption validation 
segment; if it is determined that the decrypted segment 
does not match the known clear text segment, the proc- 
ess continues at software block625 by ending; however, 
if it is determined in decision block 623 that the decrypt- 
ed validation segment does match the known clear text 
validation segment, the process continues as software 
block 627, wherein access to the called file is allowed. 
Then, the decryption type is read from the decryption 
header in accordance with software block 629, and the 
called file is dynamically decrypted in accordance with 
software block 631 as it is passed for processing by the 
operating system of the user-controlled data processing 
system, in accordance with software block 633. The 
process terminates at software block 635. 
[0051] If unauthorized execution of an encrypted file 
is attempted, the executable stub will at least temporar- 
ily deny access and post a message to the system, but 
may handle the problem in a number of sophisticated 
ways which were enumerated above. 
[0052] In accordance with the preferred embodiment 
of the present invention, during the trial interval, or at 
the conclusion of the trial interval, the prospective pur- 
chaser may contact the vendor to make arrangements 
for the purchase of a copy of the one or more software 
products on the computer-accessible memory media. 
Preferably, CD ROMs or floppy disks have been utilized 
to ship the product to the potential user. Preferably, the 
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computer-accessible memory media includes the two 
encrypted copies of each of the products which are of- 
fered for a trial interval of use. One encrypted copy may 
be decrypted utilizing the file management program and 
the temporary key which is communicated from the ven- 
dor to the purchaser. The other encrypted copy is not 
provided for use in the trial interval mode of operation, 
but instead is provided as the permanent copy which 
may be decrypted and utilized once the software prod- 
uct has been purchased. In broad overview, the user se- 
lects a software product for a trial interval mode of op- 
eration, and obtains from the vendor temporary access 
keys, which allow the user access to the product 
(through the file management program) for a predefined 
trial interval. Before or after the conclusion of the trial 
interval, the user may purchase a permanent copy of 
the software product from the vendor by contacting the 
vendor by facsimile, electronic mail, or telephone. Once 
payment is received, the vendor communicates to the 
user a permanent access key which is utilized to decrypt 
the second encrypted copy of the software product. This 
encrypted product may be encrypted utilizing any con- 
ventional encryption routine, such as the DES algorithm. 
The permanent key allows the software product to be 
decrypted for unrestricted use. Since multiple copies of 
the product may be purchased in one transaction, the 
present invention is equipped with a technique for pro- 
viding movable access keys, which will be discussed be- 
low in connection with Figures 30 through 35. In the pre- 
ferred embodiment of the present invention, the encryp- 
tion algorithm employed to encrypt and decrypt the sec- 
ond copy of the software product is similar to that em- 
ployed in the trial interval mode of operation. 
[0053] The present invention includes an export/im- 
port function which allows for the distribution of perma- 
nent access keys, after the conclusion of a trial interval 
period. Typically, an office administrator or data 
processing system manager will purchase a selected 
number of "copies" of the encrypted product after termi- 
nation of atrial interval period. Certain individuals within 
the organization will then be issued permanent keys 
which allow for the unrestricted and permanent access 
to the encrypted product. In an office or work environ- 
ment where the computing devices are not connected 
in a distributed data processing network, the permanent 
access keys must be communicated from the office ad- 
ministrator or data processing manager to the selected 
individuals within an organization who are going to re- 
ceive copies of the encrypted software product. The per- 
manent keys allow for permanent access to the product. 
Since not all employees within an organization may be 
issued copies of the particular encrypted product, the 
vendor would like to have the distribution occur in a man- 
ner which minimizes or prevents the distribution beyond 
the sales agreement or license agreement. Since the 
products are encrypted, they may be liberally distributed 
in their encrypted form. It is the keys which allow unre- 
stricted access to the product which are to be protected 



in the current invention. To prevent the distribution of 
keys on electronic mail or printed communications, the 
present invention includes an export program which is 
resident in a source computer and an import program 

5 which is resident in a target computer which allow for 
the distribution of the access keys via a removable 
memory media, such as a floppy diskette. This ensures 
that the access keys are not subject to inadvertent or 
accidental distribution or disclosure. There are two prin- 

10 cipal embodiments which accomplish this goal. 

[0054] In the first embodiment, one or more encrypted 
files which are maintained in the source computer are 
first decrypted, and then encrypted utilizing an encryp- 
tion algorithm and an encryption key which is unique to 

15 the transportable memory media (such as a diskette se- 
rial number). The key file may then be physically carried 
via the diskette to a target computer, where it is decrypt- 
ed utilizing a key which is derived by the target computer 
from interaction with the transferable memory media. 

20 Immediately, the key file or files are then encrypted uti- 
lizing an encryption operation which is keyed with a key 
which is derived from a unique system attribute of the 
target computer. 

[0055] In the alternative embodiment, the transferra- 

25 ble memory media is loaded onto the target computer 
to obtain from the target computer import file a transfer 
key which is uniquely associated with the target compu- 
ter, and which may be derived from one or more unique 
system attributes of the target computer. The memory 

30 media is then transferred to the source computer, where 
the one or more key files are decrypted, and then en- 
crypted utilizing the transfer key. The memory media is 
then carried to the target computer where the transfer 
key is generated and utilized in a decryption operation 

35 to decrypt the one or more key files. Preferably, imme- 
diately the key files are encrypted utilizing an encryption 
operation which is keyed with a key which is uniquely 
associated with the target computer, and which may be 
derived from one or more unique computer configura- 

40 tion attributes. The first embodiment is discussed herein 
in connection with Figures 30, 31 , 32, and 33. The sec- 
ond embodiment is discussed in connection with Fig- 
ures 34 and 35. 

[0056] Figures 30 and 31 depict in block diagram 
45 form export and import operations which allow an au- 
thorized user to move his permanent key to another data 
processing system using an "export" facility that produc- 
es a unique diskette image of the access key that has 
been enabled for import into another system. In accord- 
50 ance with the present invention, the access keys which 
are delivered over the telephone by the software vendor 
to the customer are less than 40 bytes in length. The 
key file that is produced is over 2,000 bytes in length. 
An export facility is provided for copying the key file and 
55 the machine identification file to a diskette. Both files are 
then encrypted with a modified diskette serial number 
to inhibit these files from being copied to a public forum 
where anyone could use them. An import facility provid- 
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ed in another system decrypts these files and adds the 
product key and machine identification from the diskette 
to a list of import product keys and machine identifica- 
tions in the import systems master file, and copies the 
key file to the import system hard disk. The key file is 
encrypted on the import system as is disclosed above. 
[0057] Figure 30 is a block diagram depiction of an 
export operation in accordance with the preferred em- 
bodiment of the present invention. As is shown, source 
computer 651 includes a key file 653 and a machine 
identification file 655. Key file 653 includes the product 
key, the customer key, the clear text of the machine iden- 
tification for source computer 653, trial interval data 
(such as a clock and/or counter which define the trial 
interval period), and an export counter which performs 
the dual functions of defining the maximum number of 
export operations allowed for the particular protected 
software products and keeping track of the total number 
of export operations which have been accomplished. 
The machine identification file includes the machine 
identification number and trial interval data (such as a 
clock and/or counter which defines the trial interval pe- 
riod). Both key file 653 and machine identification file 
655 are encrypted with any conventional encryption op- 
eration (such as the DES algorithm), which is keyed with 
a key which is derived from a unique system attribute of 
source computer 651. At the commencement of an ex- 
port operation, key file 653 and machine identification 
file 655 are decrypted. Key file 653 is supplied as an 
input to decryption operation 657 which is keyed with 
key 659. Likewise, machine identification file 655 is sup- 
plied as an input to decryption operation 663 which is 
keyed with key 661. Decryption operations 657, 663 
generate a clear text version of key file 653 and machine 
identification file 655. Once the clear text is obtained, 
the export counter which is contained within key file 653 
is modified in accordance with block 661. For example, 
if this is the seventh permitted export operation out of 
ten permissible operations, the counter might read "7: 
1 0". The clear text version of key file 653 is supplied as 
an input to encryption operation 669. Encryption opera- 
tion 669 may be any conventional encryption operation 
(such as the DES algorithm), which is keyed with a 
memory media attribute 665 which is unique to a mem- 
ory media which is coupled to source computer 651, 
which has been subjected to modification of modifier 
667. For example, a unique diskette serial number may 
be supplied as the "memory media attribute" which is 
unique to memory media 677. The diskette serial 
number is modified in accordance with modifier 667 to 
alter it slightly, and supply it as an input to encryption 
operations 669. The same operation is performed for the 
clear text of machine identification file 655. A unique 
memory media attribute 671 is modified by modifier 673 
and utilized as a key for encryption operation 675, which 
may comprise any conventional encryption operation, 
such as the DES operation. Finally, the output of encryp- 
tion operations 669 and 675 are supplied as inputs to 



copy operations 679, 681 which copy the encrypted key 
file 653 and machine identification file 655 to memory 
media 677. 

[0058] Figure 31 is a block diagram depiction of an 

5 import operation. Memory media 677 (of Figure 30) is 
physically removed from source computer 651 (of Fig- 
ure 30) and physically carried over to computer 707 (of 
Figure 31); alternatively, in a distributed data process- 
ing system, this transfer may occur without the physical 

10 removal of memory media 677. With reference now to 
Figure 31, in accordance with block 683, the machine 
identification of the target machine is copied to memory 
media 677 to maintain a record of which particular target 
computer received the key file and machine identifica- 

15 tion file. Then, in accordance with blocks 685, 693 the 
encrypted key file 653 and machine identification file 
655 are copied from the memory media to target com- 
puter 707. The encrypted key file 653 is supplied as an 
input to decryption operation 689 which is keyed with 

20 key 687. Decryption operation 689 reverses the encryp- 
tion operation of block 669, and provides as an output 
a clear text version of key file 653. Likewise, machine 
identification file 655 is supplied as an input to decryp- 
tion operation 697, which is keyed with key 695. Decryp- 
ts tion operation 697 reverses the encryption of encryption 
operation 675 and provides as an output the clear text 
of machine identification file 655. In accordance with 
block 691 , the machine identification of the source com- 
puter 651 is retrieved and recorded in memory in the 

30 clear text of key file 653. Next, the clear text of key file 
653 is supplied as an input to encryption operation 699. 
Encryption operation 699 is a conventional encryption 
operation, such as the DES operation, which is keyed 
with a target computer unique attribute, such as the ma- 

35 chine identification or modified machine identification for 
the target computer 707. The clear text of machine iden- 
tification file 655 is supplied as an input to encryption 
operation 703. Encryption operation 703 is any conven- 
tional encryption operation, such as the DES encryption 

40 operation, which is keyed with a unique target computer 
attribute 705, such as machine identification or modified 
machine identification of target computer 707. The out- 
put of encryption operation 699 produces an encrypted 
key file 709 which includes a product key (which is the 

45 same temporary product key of key file 653 of source 
computer 651 ), a customer number (which is the same 
customer number of key file 653 of source computer 
651), and clear machine identification (which is the ma- 
chine identification for target computer 707, and not that 

50 of source computer 651), trial interval data (which is 
identical to the trail interval data of key file 653 of source 
651), and an identification of the machine identification 
of the source computer 651. The output of encryption 
operation 703 defines machine identification file 711, 

55 which includes the machine identification of the target 
computer 707 (and not that of the source computer 651), 
and the trial interval data (which is identical to that of 
machine identification file 655 of source computer 651 ). 
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[0059] Figures 32 and 33 provide alternative views of 
the import and export operations which are depicted in 
Figures 30 and 31 , and emphasize several of the impor- 
tant features of the present invention. As is shown, 
source computer 801 includes machine identification file 
803 which is encrypted with a system attribute key which 
is unique to the source computer 801. The machine 
identification file includes machine identification file 
number as well as count of the number of exports al- 
lowed for each protected software product, and a count 
of the total number of exports which have been utilized. 
For example, the first export operation carries a count 
of "1 :1 0", which signifies that one export operation often 
permitted export operations has occurred. In the next 
export operation, the counter is incremented to "2:20" 
which signifies that two of the total number of ten per- 
mitted export operations has occurred. Each target 
computer which receives the results of the export oper- 
ation is tagged with this particular counter value, to iden- 
tify that it is the recipient of a particular export operation. 
For example, one source computer system may carry a 
counter value of "1 :1 0", which signifies that it is the re- 
cipient of the first export operation of ten permitted ex- 
port operations. Yet another target computer may carry 
the counter value of "7:10", which signifies that this par- 
ticular target computer received the seventh export op- 
eration of a total of ten permitted export operations. In 
this fashion, the target computer maintains a count of a 
total number of used export operations, while the source 
computers each carry a different counter value which 
identifies it a the recipient of the machine identification 
file and key file from the source computer from particular 
ones of the plurality of permitted export operations. 
[0060] Note that in source computer 801 machine 
identification file 803 and key file 805 are encrypted with 
an encryption algorithm which utilizes as a key a system 
attribute which is unique to source computer 801 ; how- 
ever, once machine identification file 803 and key file 
805 are transferred to a memory media, such as export 
key diskette 807, machine identification file 809 and key 
file 81 1 are encrypted in any conventional encryption op- 
eration which utilizes as an encryption key a unique dis- 
kette attribute, such as the diskette's serial number. This 
minimizes the possibility that the content of the machine 
ID file 809 and/or key file 811 can be copied to another 
diskette or other memory media and then utilized to ob- 
tain unauthorized access to the software products. This 
is so because for an effective transfer of the content of 
machine ID file 809 and key file 811 to a target computer 
to occur, the target computer must be able to read and 
utilize the unique diskette attribute from the export key 
diskette 807. Only when the machine I D file 809 and key 
file 811 are presented to a target computer on the dis- 
kette onto which these items were copied can an effec- 
tive transfer occur. The presentation of the machine ID 
file 809 and key file 811 on a diskette other than export 
key diskette 807 to a potential target computer will result 
in the transfer of meaningless information, since the 



unique attribute of export key diskette 807 (such as the 
diskette serial number) is required by the target compu- 
ter in order to successfully accomplish the decryption 
operation. 

5 [0061] As is shown in Figure 33, export key diskette 
807 is presented to target computer 81 3. Of course, the 
machine identification file 809 and key file 81 1 are in en- 
crypted form. In the transfer from export key diskette 807 
to target computer 813, the content of machine ID file 

10 809 is updated with the machine identification of the tar- 
get computer 813, and the count of imports utilized. In 
accomplishing the transfer to target computer 813, a 
machine identification file 815 is constructed which in- 
cludes a number of items such as machine identification 

15 for the target computer 813, customer information, as 
well as a list of the machine identification number of the 
source computer 801. Both machine identification file 
815 and the key file 817 are encrypted utilizing a con- 
ventional encryption operation which uses as a key a 

20 unique attribute of target computer 813. This ties ma- 
chine identification file 815 and key file 817 to the par- 
ticular target computer 813. 

[0062] By using an export/import counter to keep 
track of the total number of authorized export/import op- 

25 erations, and the total number of used export/import op- 
erations, the present invention creates an audit trail 
which can be utilized to keep track of the distribution of 
software products during the trial interval. Each source 
computer will carry a record of the total number of export 

30 operations which have been performed. Each source 
computer will carry a record of which particular export/ 
import operation was utilized to transfer one or more 
protected software products to the target computer. The 
memory media utilized to accomplish the transfer (such 

35 as a diskette, or group of diskettes) will carry a perma- 
nent record of the machine identification numbers of 
both the source computer and the target computer's uti- 
lized in all export/import operations. 
[0063] The procedure for implementing export and 

40 import operations ensures that the protected software 
products are never exposed to unnecessary risks. 
When the machine identification file and key file are 
passed from the source computer to the export diskette, 
they are encrypted with the unique attribute of the export 

45 diskette which prevents or inhibits copying of the export 
diskette or posting of its contents to a bulletin board as 
a means for illegally distributing the keys. During the im- 
port operations, the machine identification and key files 
are encrypted with system attributes which are unique 

50 to the target computer to ensure that the software prod- 
ucts are maintained in a manner which is consistent with 
the security of the source computer, except that those 
software products are encrypted with attributes which 
are unique to the target computer, thus preventing illegal 

55 copying and posting of the keys. 

[0064] The second embodiment of the export/import 
function is depicted in block diagram form in Figures 34 
and 35. In broad overview, memory media 1677 is first 
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utilized to interact with target computer 1707 to obtain 
from target computer 1707 a transfer key which is 
unique to target computer 1 707, and which is preferably 
derived from one or more unique system attributes of 
target computer 1707. The transfer key may be a mod- 
ification of the machine identification for target computer 
1707. Next, the memory media 1677 is utilized to inter- 
act with source computer 1 651 in an export mode of op- 
eration, wherein key file 1 653 and machine identification 
file 1 655 are first decrypted, and then encrypted utilizing 
the transfer key. 

[0065] Figure 34 is a block diagram depiction of an 
export operation in accordance with the preferred em- 
bodiment of the present invention. As is shown, source 
computer 1 651 includes a key file 1 653 and a machine 
identification file 1655. Key file 1653 includes the prod- 
uct key, the customer key, the clear text of the machine 
identification for source computer 1 653, trial interval da- 
ta (such as a clock and/or counter which define the trial 
interval period), and an export counter which performs 
the dual functions of defining the maximum number of 
export operations allowed for the particular protected 
software products and keeping track of the total number 
of export operations which have been accomplished. 
The machine identification file includes the machine 
identification number and trial interval data (such as a 
clock and/or counter which defines the trial interval pe- 
riod). Both key file 1653 and machine identification file 
1655 are encrypted with any conventional encryption 
operation (such as the DES algorithm), which is keyed 
with a key which is derived from a unique system at- 
tribute of source computer 1 651 . At the commencement 
of an export operation, key file 1 653 and machine iden- 
tification file 1655 are decrypted. Key file 1653 is sup- 
plied as an input to decryption operation 1657 which is 
keyed with key 1659. Likewise, machine identification 
file 1 655 is supplied as an input to decryption operation 
1663 which is keyed with key 1661. Decryption opera- 
tions 1 657, 1 663 generate a clear text version of key file 
1653 and machine identification file 1655. Once the 
clear text is obtained, the export counter which is con- 
tained within key file 1 653 is modified in accordance with 
block 1 661 . For example, if this is the seventh permitted 
export operation out of ten permissible operations, the 
counter might read "7:10". The clear text version of key 
file 1 653 is supplied as an input to encryption operation 
1669. Encryption operation 1669 may be any conven- 
tional encryption operation (such as the DES algorithm), 
which is keyed with the transfer key 1 665 which was pre- 
viously obtained. The same operation is performed for 
the clear text of machine identification file 1655. Trans- 
fer key 1 671 is utilized as a key for encryption operation 
1 675, which may comprise any conventional encryption 
operation, such as the DES operation. Finally, the output 
of encryption operations 1 669 and 1 675 are supplied as 
inputs to copy operations 1679, 1681 which copy the 
encrypted key file 1653 and machine identification file 
1655 to memory media 1677. 



[0066] Figure 35 is a block diagram depiction of an 
import operation. Memory media 1677 (of Figure 34) is 
physically removed from source computer 1 651 (of Fig- 
ure 34) and physically carried over to computer 1 707 (of 

5 Figure 35); alternatively, in a distributed data processing 
system, this transfer may occur without the physical re- 
moval of memory media 1677. With reference now to 
Figure 35, in accordance with block 1683, the machine 
identification of the target machine is copied to memory 

10 media 1 677 to maintain a record of which particular tar- 
get computer received the key file and machine identi- 
fication file. Then, in accordance with blocks 1 685, 1 693 
the encrypted key file 1653 and machine identification 
file 1655 are copied from the memory media to target 

15 computer 1 707. The encrypted key file 1 653 is supplied 
as an input to decryption operation 1 689 which is keyed 
with key 1687. Decryption operation 1689 reverses the 
encryption operation of block 1669, and provides as an 
output a clear text version of key file 1653. Likewise, 

20 machine identification file 1655 is supplied as an input 
to decryption operation 1697, which is keyed with key 
1695. Decryption operation 1697 reverses the encryp- 
tion of encryption operation 1675 and provides as an 
output the clear text of machine identification file 1 655. 

25 in accordance with block 1691, the machine identifica- 
tion of the source computer 1651 is retrieved and re- 
corded in memory in the clear text of key file 1 653. Next, 
the clear text of key file 1653 is supplied as an input to 
encryption operation 1699. Encryption operation 1699 

30 is a conventional encryption operation, such as the DES 
operation, which is keyed with a target computer unique 
attribute, such as the machine identification or modified 
machine identification for the target computer 1707. The 
clear text of machine identification file 1655 is supplied 

35 as an input to encryption operation 1 703. Encryption op- 
eration 1703 is any conventional encryption operation, 
such as the DES encryption operation, which is keyed 
with a unique target computer attribute 1705, such as 
machine identification or modified machine identifica- 

40 tion of target computer 1707. The output of encryption 
operation 1699 produces an encrypted key file 1709 
which includes a product key (which is the same tem- 
porary product key of key file 1653 of source computer 
1651), a customer number (which is the same customer 

45 number of key file 1653 of source computer 1651), and 
clear machine identification (which is the machine iden- 
tification for target computer 1707, and not that of source 
computer 1651), trial interval data (which is identical to 
the trail interval data of key file 1653 of source 1651), 

50 and an identification of the machine identification of the 
source computer 1651. The output of encryption oper- 
ation 1703 defines machine identification file 1711, 
which includes the machine identification of the target 
computer 1707 (and not that of the source computer 

55 1651), and the trial interval data (which is identical to 
that of machine identification file 1655 of source com- 
puter 1651). 
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Claims 

1 . A method of distributing a software object (10) from 
a source (209) to a user (21 1 ), comprising the meth- 
od steps of providing a software object (201), en- 
crypting said software object (201) with an encryp- 
tion operation utilizing a long-lived encryption key 
(203; 271; 281), directing said encrypted software 
object (207) from said source (209) to said user 
(21 1), loading said encrypted software object (207) 
onto a user-controlled data processing system (10) 
having a particular configuration (353), deriving a 
numerical machine identification (357) based at 
least in part upon said particular configuration (353) 
of said user-controlled data processing system 
(10), the method being characterized by the steps 
of: 

communicating said numerical machine identi- 
fication (357) to the source operator (209); 

deriving a temporary key (377) based at least 
in part upon said numerical machine identifica- 
tion (357) and said long-lived encryption key 
(371 ;381 ;203); 

communicating said temporary key (377) from 
said source (209) to said user (211); 

providing a long-lived key generator (379) for 
receiving said temporary key (377) and produc- 
ing said long-lived encryption key (371 ; 381 ; 
203) at said user; and 

allowing said user (211) to utilize said tempo- 
rary key (377) for a prescribed interval to gen- 
erate said long-lived encryption key (371 ; 381 ; 
203) to access said software object (201). 

2. A method of distributing a software object (201 ) ac- 
cording to Claim 1 , wherein said encrypted software 
object (207) is recorded onto a computer-accessi- 
ble memory media and directed from said source 
(209) to said user (211). 

3. A method of distributing a software object (201 ) ac- 
cording to Claim 1 or 2, wherein said long-lived key 
generator (279) is recorded onto a computer-acces- 
sible memory media and directed from said source 
(209) to said user (211) along with said encrypted 
software object (207). 

4. A method of distributing a software object (201 ) ac- 
cording to one of Claims 1 to 3, further comprising 
the method steps of: 

providing afile managementprogram, which in- 
cludes said long-lived key generator (279) as a 



component thereof; and 

directing said file management program from 
said source (209) to said user (21 1 ) along with 
5 said encrypted software object (207). 

5. A method of distributing a software object (201 ) ac- 
cording to one of Claims 1 to 4, further comprising 
the method steps of: 

10 

creating a key file (397; 653; 709) in said user- 
controlled data processing system (10) for re- 
cording at least said temporary key (377). 

15 6. A method of distributing a software object (201 ) ac- 
cording to Claim 5, further comprising the method 
steps of: 

encrypting said key file (397; 653; 709) utilizing 
20 at least one unique system attribute (421) as 

an encryption key (401). 

7. A method of distributing software objects (201 ) from 
a producer (209) to a user (211), comprising the 

25 method steps of providing a software object (201), 
providing a computer-accessible memory media, 
providing a file management program, encrypting 
said software object (201) utilizing a long-lived key 
(203; 371 ; 381), recording said encrypted software 

30 object (207) onto said computer-accessible memo- 
ry media, shipping said computer-accessible mem- 
ory from said producer (209) to said user (211), 
loading said file management program into a user- 
controlled data processing system (10) and associ- 

35 ating it with an operating system for said user-con- 
trolled data processing system (10), reading said 
computer-accessible memory with said user-con- 
trolled data processing system (10), 
the method being characterized by the steps of: 

40 

utilizing said file management program to de- 
rive a numerical machine identification (357) 
based upon at least one attribute (353) of said 
user-controlled data processing system (10); 

45 

deriving a temporary key (377) based at least 
in part upon said numerical machine identifica- 
tion (357); 

50 utilizing said file management program by exe- 

cuting it with said user-controlled data process- 
ing system (10) to restrict access to said soft- 
ware object (201 ) for an interval defined by said 
temporary key (377); and 

55 

providing a long-lived key generator (379) in 
said user-controlled data processing system 
(10) which provides said long-lived key (203; 
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271 ; 281 ) in response to receipt of at least said 
temporary key (377). 

8. A method of distributing software objects (201) ac- 
cording to Claim 7, wherein said file management 
program is operable in a plurality of modes of oper- 
ation when executed by said user-controlled data 
processing system (10), including the following 
modes of operation: 

(a) a temporary trial mode of operation, wherein 
said software object (201) is temporarily ena- 
bled by utilizing said temporary key (377); 

(b) a permanent use mode of operation, where- 
in said software object (201) is permanently en- 
abled, allowing unlimited use of said software 
object (201 ) by said user (211). 

9. A computer system having means for performing 
the steps of a method according to one of the pre- 
ceding claims 1 to 8. 



Patentanspruche 

1. Ein Verfahren zum Verteilen eines Software-Ob- 
jekts (10) aus einer Quelle (209) an einen Anwen- 
der (21 1 ), enthaltend die Verfahrensschritte: Vorse- 
hen eines Software-Objekts (201), Verschlusseln 
des Software-Objekts (201) mit einer Verschlusse- 
lungsoperation unter Benutzung eines langlebigen 
Verschlusselungs-Schlussels (203, 271, 281), 
Richten des verschlusselten Software-Objekts 
(207) von der Quelle (209) zum Anwender (211), 
Laden des verschlusselten Software-Objekts (207) 
in das anwender-gesteuerte Datenverarbeitungs- 
system (10) mit einer besonderen Konfiguration 
(353), Ableiten einer numerischen Maschineniden- 
tifizierung (357) auf der Grundlage, mindestens teil- 
weise, der besonderen Konfiguration (353) des an- 
wender-gesteuerten Datenverarbeitungssystems 
(10), 

wobei das Verfahren durch die folgenden Schritte 
gekennzeichnet ist: 



Vorsehen eines langlebigen Schlussel-Gene- 
rators (379) zum Empfangen des temporaren 
Schlussels (377) und Erzeugen des langlebi- 
gen Verschlusselungs-Schlussels (371; 381; 
5 203) beim Anwender; und 

Zulassen, dass der Anwender (211) den tem- 
poraren Schlussel (377) wahrend eines vorge- 
gebenen Intervalls benutzt, urn die langlebigen 
10 Verschlijsselungs-Schlussel (371 ; 381 ; 203) zu 

generieren, urn auf das Software-Objekt (201) 
Zugriff zu nehmen. 

2. Ein Verfahren zum Verteilen eines Software-Ob- 
15 jekts (201) gemaB Anspruch 1, in dem das ver- 

schlusselte Software-Objekt (207) auf einem com- 
puter-zugreifbaren Speichermedium aufgezeichnet 
ist und von der Quelle (209) zum Anwender (211) 
gerichtet wird. 

20 

3. Ein Verfahren zum Verteilen eines Software-Ob- 
jekts (201) gemaB Anspruch 1 oder 2, in dem der 
langlebige Schlusselgenerator (279) auf ein com- 
puter-zugreifbares Speichermedium aufgezeichnet 

25 ist und zusammen mit dem verschlusselten Soft- 
ware-Objekt (207) von der Quelle (209) zum An- 
wender (211) gerichtet wird. 

4. Ein Verfahren zum Verteilen eines Software-Ob- 
30 jekts (201) gemaB einem der Anspruche 1 bis 3, das 

ferner die folgenden Verfahrensschritte enthalt: 

Vorsehen eines Dateiverwaltungsprogramms, 
das den langlebigen Schlusselgenerator (279) 
35 als eine Komponente desselben beinhaltet; 

und 

Richten des Dateiverwaltungsprogramms von 
der Quelle (209) zum Anwender (211) zusam- 
40 men mit dem verschlusselten Software-Objekt 

(207). 

5. Ein Verfahren zum Verteilen eines Software-Ob- 
jekts (201 ) gemaB einem der Anspruche 1 bis 4, das 

45 ferner die folgenden Verfahrensschritte enthalt: 



Ubermitteln der numerischen Maschineniden- 
tifizierung (357) an den Quellen-Operator 
(205); 

Ableiten eines temporaren Schlussels (377), 
auf der Grundlage, mindestens teilweise, der 
numerischen Maschinenidentifizierung (357) 
und des langlebigen Verschlusselungs-Schlus- 
sels (371; 381; 203); 

Ubermitteln des temporaren Schlussels (377) 
von der Quelle (209) zum Anwender (211); 



Erstellen einer Schlusseldatei (397; 653; 709) 
im anwender-gesteuerten Datenverarbei- 
tungssystem (10) zum Aufzeichnen wenig- 
50 stens des temporaren Schlussels (377). 

6. Ein Verfahren zum Verteilen eines Software-Ob- 
jekts (201) gemaB Anspruch 5, das ferner die fol- 
genden Verfahrensschritte enthalt: 

55 

Verschlusseln der Schlusseldatei (397; 653; 
709) unter Verwendung wenigstens eines ein- 
deutigen System attributs (421) als einen Ver- 
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schlusselungs-Schlussel (401). 

7. Ein Verfahren zum Verteilen von Software-Objek- 
ten (201) von einem Hersteller (209) an einen An- 
wender (211). enthaltend die folgenden Verfahrens- 5 
schritte: Vorsehen eines Software-Objekts (201), 
Vorsehen eines computer-zugreifbaren Speicher- 
mediums, Vorsehen eines Dateiverwaltungspro- 
gramms, Verschlusseln des Software-Objekts 
(201) unter Verwendung eines langlebigen Schlus- 10 
sels (203; 31 7; 381 ), Aufzeichnen des verschlussel- 

ten Software-Objekts (207) auf das computerzu- 
greifbare Speichermedium, Senden des computer- 
zugreifbaren Speichers vom Hersteller (209) an 
den Anwender (21 1 ), Laden des Dateiverwaltungs- 15 
programms in ein anwender-gesteuertes Datenver- 
arbeitungssystem (1 0) und Zuordnen desselben zu 
einem Betriebssystem fur das anwender-gesteuer- 
te Datenverarbeitungssystem (1 0), Lesen des com- 
puter-zugreifbaren Speichers mit dem anwender- 20 
gesteuerten Datenverarbeitungsystem (10), 
wobei das Verfahren durch die folgenden Schritte 
gekennzeichnet ist: 

Benutzen des Dateiverwaltungsprogramms 25 
zum Ableiten einer numerischen Maschineni- 
dentifizierung (357) auf der Grundlage von min- 
destens einem Attribut (353) des anwender-ge- 
steuerten Datenverarbeitungssystems (10): 

30 

Ableiten eines temporaren Schlussels (377) 
auf der Grundlage, mindestens teilweise, der 
numerischen Maschinenidentifizierung (357): 

Benutzen des Dateiverwaltungsprogramms 35 
durch Ausfuhren desselben mit dem anwen- 
der-gesteuerten Datenverarbeitungssystem 
(10), urn den Zugriff auf das Software-Objekt 
(201) wahrend eines durch den temporaren 
Schlussel (377) definierten Intervalls zu be- 40 
schranken; und 

Vorsehen eines langlebigen Schlusselgenera- 
tors (379) im anwender-gesteuerten Datenver- 
arbeitungssystem (1 0), das diesen langlebigen 45 
Schlussel (203; 271 ; 291 ) als Reaktion auf den 
Eingang wenigstens des temporaren Schlus- 
sels (377) vorsieht. 

8. Ein Verfahren zum Verteilen von Software-Objek- 50 
ten (201) gemaB Anspruch 7, in dem das Dateiver- 
waltungsprogramm in einer Vielzahl von Betriebs- 
modi betreibbar ist, wenn es von dem anwender- 
gesteuerten Datenverarbeitungssystem (10) aus- 
gefuhrt wird, einschlieBlich der folgenden Betriebs- 55 
modi: 

(a) Ein temporarer Versuchsbetriebsmodus, in 



dem das Software-Objekt (201) durch Benut- 
zen des temporaren Schlussels (377) temporar 
aktiviert wird; 

(b) Ein permanenter Betriebsmodus, in dem 
das Software-Objekt (201) permanent aktiviert 
ist, und die uneingeschrankte Anwendung des 
Software-Objekts (201) durch den Anwender 
(211) zulasst. 

9. Ein Computersystem mit Mitteln zur Durchfuhrung 
der Schritte eines Verfahrens gemaB einem der vor- 
stehenden Anspruche 1 bis 8. 



Revendications 

1. Procede de distribution d'un objet de logiciel (10) 
d'une source (209) a un utilisateur (211), compre- 
nant les etapes de procede consistant a fournir un 
objet de logiciel (201 ), acrypter ledit objet de logiciel 
(201 ) avec une operation de cryptage utilisant une 
cle de cryptage a longue duree de vie (203 ; 271 ; 
281 ), a diriger ledit objet de logiciel crypte (207) de- 
puis ladite source (209) vers ledit utilisateur (211), 
a charger ledit objet de logiciel crypte (207) sur un 
systeme de traitement de donnees commande par 
I'utilisateur (10) presentant une configuration parti- 
culiere (353), aobtenir une identification numerique 
de machine (357) sur la base au moins en partie de 
ladite configuration particuliere (353) dudit systeme 
de traitement de donnees commande par un utili- 
sateur (1 0), 

le procede etant caracterise par les etapes consis- 
tant a : 

communiquer ladite identification numerique 
de machine (357) a I'operateur source (209), 

obtenir une cle temporaire (377) sur la base au 
moins en partie de ladite identification numeri- 
que de machine (357) et de ladite cle de cryp- 
tage a longue duree de vie (371 ; 381 ; 203), 

communiquer ladite cle temporaire (377) de- 
puis ladite source (209) audit utilisateur (211), 

fournir un generateur de cle a longue duree de 
vie (379) destine a recevoir ladite cle temporai- 
re (377) et a produire ladite cle de cryptage a 
longue duree de vie (371 ; 381 ; 203) au niveau 
dudit utilisateur, et 

permettre audit utilisateur (211) d'utiliser ladite 
cle temporaire (377) pendant un intervalle pres- 
ent, pour generer ladite cle de cryptage a lon- 
gue duree de vie (371 ; 381 ; 203) afin d'acceder 
audit objet de logiciel (201). 
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2. Procede de distribution d'un objet de logiciel (201 ) 
selon la revendication 1 , dans lequel ledit objet de 
logiciel crypte (207) est enregistre sur un support 
de memoire accessible a un ordinateur et dirige de- 
puis ladite source (209) vers ledit utilisateur (211). 

3. Procede de distribution d'un objet de logiciel (201 ) 
selon la revendication 1 ou 2, dans lequel ledit ge- 
nerates de cle a longue duree de vie (279) est en- 
registre sur un support de memoire accessible a un 
ordinateur et dirige depuis ladite source (209) vers 
ledit utilisateur (21 1 ) en meme temps que ledit objet 
de logiciel crypte (207). 

4. Procede de distribution d'un objet de logiciel (201 ) 
selon I'une des revendications 1 a 3, comprenant 
en outre les etapes de procede consistant a : 

fournir un programme de gestion de fichiers, 
qui comprend ledit generateur de cle a longue 
duree de vie (279) en tant que composant de 
celui-ci, et 

diriger ledit programme de gestion de fichiers 
depuis ladite source (209) vers ledit utilisateur 
(21 1 ) en meme temps que ledit objet de logiciel 
crypte (207) 

5. Procede de distribution d'un objet de logiciel (201 ) 
selon I'une des revendications 1 ou 4, comprenant 
en outre les etapes de procede consistant a : 

creer un fichier de cle (397, 653 ; 709) dans le- 
dit systeme de traitement de donnees com- 
mande par un utilisateur (10) afin d'enregistrer 
au moins ladite cle temporaire (377). 

6. Procede de distribution d'un objet de logiciel (201 ) 
selon la revendication 5, comprenant en outre les 
etapes de procede consistant a : 

crypter ledit fichier de cle (397 ; 653 ; 709) en 
utilisant au moins un attribut de systeme unique 
(421 ) en tant que cle de cryptage (401 ). 

7. Procede de distribution d'objets de logiciel (201 ) de- 
puis un fabricant (209) vers un utilisateur (211), 
comprenant les etapes de procede consistant a 
fournir un objet de logiciel (201), afournirun support 
de memoire accessible a un ordinateur, a fournir un 
programme de gestion de fichiers, acrypter ledit ob- 
jet de logiciel (201 ) en utilisant une cle a longue du- 
ree de vie (203 ; 371 ; 381 ), a enregistrer ledit objet 
de logiciel crypte (207) sur ledit support de memoire 
accessible a un ordinateur, a expedier ladite me- 
moire accessible a un ordinateur depuis ledit fabri- 
cant (209) vers ledit utilisateur (21 1 ), a charger ledit 
programme de gestion de fichiers dans un systeme 



de traitement de donnees commande par un utili- 
sateur (1 0) et I'associer a un systeme d'exploitation 
pour ledit systeme de traitement de donnees com- 
mande par un utilisateur (1 0), a lire ladite memoire 
5 accessible a un ordinateur avec ledit systeme de 

traitement de donnees commande par un utilisateur 
(10), 

le procede etant caracterise par les etapes consis- 
tant a : 

10 

utiliser ledit programme de gestion de fichiers 
pour obtenir une identification numerique de 
machine (357) sur la base au moins d'un attri- 
but (353) dudit systeme de traitement de don- 
15 nees commande par un utilisateur (1 0), 

obtenir une cle temporaire (377) sur la base au 
moins en partie de ladite identification numeri- 
que de machine (357), 

20 

utiliser ledit programme de gestion de fichiers 
en I'executant avec ledit systeme de traitement 
de donnees commande par un utilisateur (10) 
afin de restreindre un acces audit objet de lo- 
25 giciel (201 ) pendant un intervalle defini par la- 

dite cle temporaire (377), et 

fournir un generateur de cle a longue duree de 
vie (379) dans ledit systeme de traitement de 
30 donnees commande par un utilisateur (1 0) qui 

fournit ladite cle a longue duree de vie (203 ; 
271 ; 281) en reponse a une reception d'au 
moins ladite cle temporaire (377). 

35 8. Procede de distribution d'objets de logiciel (201) se- 
lon la revendication 7, dans lequel ledit programme 
de gestion de fichiers peut etre mis en oeuvre dans 
une pluralite de modes de fonctionnement lorsqu'il 
est execute par ledit systeme de traitement de don- 

40 nees commande par un utilisateur (1 0), comprenant 
les modes de fonctionnement suivants : 

(a) un mode de fonctionnement d'essai tempo- 
raire, dans lequel ledit objet de logiciel (201 ) est 

45 temporairement valide en utilisant ladite cle 

temporaire (377), 

(b) un mode de fonctionnement en utilisation 
permanente, dans lequel ledit objet de logiciel 

50 (201) est valide de facon permanente, en per- 

mettant une utilisation non limitee dudit objet 
de logiciel (201) par ledit utilisateur (211). 

9. Systeme informatique comportant un moyen pour 
55 executer les etapes d'un procede selon I'une des 
revendications precedentes 1 a 8. 
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